home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.cs.arizona.edu
/
ftp.cs.arizona.edu.tar
/
ftp.cs.arizona.edu
/
icon
/
newsgrp
/
group97a.txt
/
000065_icon-group-sender _Tue Mar 4 01:41:06 1997.msg
< prev
next >
Wrap
Internet Message Format
|
2000-09-20
|
1KB
Received: by cheltenham.cs.arizona.edu; Tue, 4 Mar 1997 08:23:28 MST
Date: Tue, 4 Mar 1997 01:41:06 -0600
Message-Id: <199703040741.BAA05683@segfault.cs.utsa.edu>
From: Clinton Jeffery <jeffery@segfault.cs.utsa.edu>
To: espie@fregate.ens.fr
Cc: icon-group@cs.arizona.edu
In-Reply-To: <5f1r3u$b7l@nef.ens.fr> (espie@fregate.ens.fr)
Subject: Re: Icon and two-dimensional matching
Reply-To: jeffery@cs.utsa.edu
Errors-To: icon-group-errors@cs.arizona.edu
Status: RO
Content-Length: 694
[Marc Espie wrote:]
> I've got cases where everything ended up in one or two buckets,
> or rather larger sets where the hashing process failed due to the
> sheer size of the data.
Interesting. I will agree that it might be useful to be able to specify
your own hashing function. It is true that tables with millions of elements
use a LOT of memory. But given a computer with enough memory the tables
scale up very well to large size, thanks to work by Bill Griswold and
Gregg Townsend. The number of buckets increases dynamically.
Clint Jeffery
jeffery@cs.utsa.edu
Division of Computer Science, The University of Texas at San Antonio
Research http://www.cs.utsa.edu/research/plss.html